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Abstract. Dynamic languages are praised for their flexibility and ex¬ 
pressiveness, but static analysis often yields many false positives and 
verification is cnmbersome for lack of structnre. Hence, nnit testing is 
the prevalent incomplete method for validating programs in such lan¬ 
guages. 

Falsification is an alternative approach that uncovers definite errors in 
programs. A falsifier computes a set of inputs that definitely crash a 
program. 

Success typing is a type-based approach to document programs in dy¬ 
namic languages. We demonstrate that success typing is, in fact, an in¬ 
stance of falsification by mapping success (input) types into suitable logic 
formulae. Output types are represented by recursive types. We prove the 
correctness of our mapping (which establishes that success typing is fal¬ 
sification) and we report some experiences with a prototype implemen¬ 
tation. 


1 Introduction 

Dynamic languages like JavaScript, Python, and Erlang are increasingly used in 
application domains where reliability and robustness matters. Their advantages 
lie in the provision of domain specific libraries, flexibility, and expressiveness, 
which enables rapid prototyping. However, massive unit testing with all its draw¬ 
backs is the primary method of discovering errors: static analysis is often not 
applicable because it either yields many false positives or restricts the expres¬ 
siveness. Verification is feasible but cumbersome (see for example the JavaScript 
formalization effort [3,6]). Moreover, it requires a major effort. 

Unit testing with good code coverage is not straightforward to achieve, either. 
As the development of meaningful unit tests is also cumbersome and time con¬ 
suming, the lack of static analyses that permit error detection prior to execution 
is one of the major drawbacks of dynamic languages. 

Classical static analyses and type systems guarantee the absence of a par¬ 
ticular class of errors: the program cannot go wrong. Imposing such a system 
on a dynamic language deprives it of its major attraction for certain program¬ 
mers: the ability to write code without being restricted by a formal framework. 
Even suggesting such a framework would come close to treason. Furthermore, 


programmers are confused by false positives or error messages they do not under¬ 
stand [2]. However, an analysis that only reports problems that would definitely 
lead to an error during execution could be acceptable. This point of view leads 
to the idea of a success typing. 

In a standard type system, the typing F : ti ^ T 2 means that an application 
of F to an argument v of type ri yields a result of type T 2 if F{v) terminates 
normally. If type checking for the system is decidable, then there are programs 
which do not lead to type mismatches when executed, but which are rejected 
by the type system. A trivial example is a conditional that returns values of 
different types in its branches, but semantically it is clear that only the first 
branch can ever be executed. 

In contrast, a success type system guarantees that for all arguments v not of 
type Ti, the function application F(v) leads to a run-time error (or nontermina¬ 
tion). For an argument v of type ri, success typing gives the same guarantees as 
traditional typing: F(v) G T 2 if it terminates normally. By necessity, the guar¬ 
antee of the run-time error is also an approximation, but success typing must 
approximate in the other direction as a standard type system. Hence, the “stan¬ 
dard part” of a success type usually gives a weaker guarantee than a standard 
type. In model checking terms, a standard type system performs verification 
whereas success typing seems related to falsification [1]: its goal is the detection 
of errors rather than proving the absence of them. 


1.1 Success Typings in Erlang 

Erlang is a dynamically typed functional programming language with commer¬ 
cial uses in e-commerce, telephony, and instant messaging. Besides the usual 
numeric and string types. Erlang includes an atom data type for symbols and 
tuples for building data structures. 

Lindahl and Sagonas [10,14] designed a success typing system for Erlang 
which infers types with a constraint-based algorithm. Types are drawn from 
a finite lattice that encompasses types for various atoms (symbols, numbers, 
strings, etc), functions, tuple and list constructions, unions, and a type any that 
subsumes all other types. One of the major goals of their approach is the ability 
to automatically generate documentation for functions from the inferred success 
types. This goal requires small, readable types, which are guaranteed by the 
finiteness of the lattice. Types for data structures are made finite by cutting off 
at a certain depth bound. A concrete example shows where this boundedness 
leads to approximation. 

Many Erlang programming idioms rely on named tuples, that is, tuples where 
the first component is an atom and the remaining components contain associ¬ 
ated data as in {book,”Hamlet”,”Shakespeare”}. One can view named tuples 
as named constructors: book(”Hamlet”,”Shakespeare”). Named tuples can be 
nested arbitrarily and created dynamically. 

Lindahl and Sagonas’ algorithm misses some definite errors based on nested 
named tuples, as can be seen by the following example. Here is an implementation 



of a list length function returning the zero constructor and succ constructor 
instead of the built-in integers.^ 

length([]) — > {zero}; 

length ([_ IXS] ) —> {succ, length (XS)}. 

The Dialyzer^ infers the following success type for length: 

length : [any] zero U succ(zero U succ(zero) U s\icc{any)) 

The argument part of the success type, [any] , describes that applying length to 
a non-list argument yields an error and applying it to a list of arbitrary content 
might succeed or fail. The result part describes the return value as either zero or 
as a nested tuple consisting of succ and any value. The argument part is exact: 
There is no argument of type [any] for which length fails. However, the analyzer 
restricts tuples to a nesting depth of three levels. 

To illustrate the problem with this approximation, consider the function 
check that pattern matches on a nest of named tuples, which cannot be created 
by the length function. Applying the check function to the result of length 
yields a definite error. However, the standard setting of the Dialyzer does not 
detect this error. 

check({succ ,{succ ,{succ ,{foo }}}}) -> 0- 
test 0 —> check (length([ 0 ,0 ,0,0])). 


1.2 Our Approach 

We focus on errors that include the creation and destruction of data structures 
and thus consider programs that manipulate constructor trees, only. Our ap¬ 
proach describes input type and output type of a function with different models. 
A success typing of a function comprises a recursive type describing the possi¬ 
ble outputs and of a crash condition as a logical formula whose models are the 
crashing inputs of the function. This approach yields a modular definition of 
success typings. 

Contributions 

— We propose a new formally defined view of success typing for a language 
with data structures. We represent the input and output types of a function 
differently and thus obtain a modular approach. 

— Our approach is correct. We show preservation of types and crash condition 
during evaluation as well as failure consistency (i.e., if our analysis predicts 
a crash, the evaluation crashes definitely). 

— We give a prototype implementation of our approach. 

^ The left-hand side pattern [] matches the empty list and the pattern [ _ | XS] matches 
a list with arbitrary head and tail bound to XS. 

^ The Discrepancy AnalYZer for ERlang programs, an implementation of Lindahl and 
Sagonas’ algorithm, http://www.erlang.org/doc/man/dialyzer.html 



Outline In Section 2 we define syntax and semantics of a constructor-based lan¬ 
guage. We introduce types and crash conditions for expressions of this language 
in Section 3 followed by an analysis that assigns types and crash conditions to 
expressions. Afterwards, we show show the correctness of the analysis. We dis¬ 
cuss practical issues of our approach in Section 4. In Section 5 we discuss related 
work and conclude in Section 6. 

An extended version of this article, including proofs, is available online [8]. 


2 Language 

We illustrate our approach using a higher-order call-by-value language Ac that 
comprises of explicit recursion, integer values, n-ary constructors, and pattern¬ 
matching to distinguish and destruct the previously defined constructors. We 
draw these constructors from a fixed, finite, and distinct ranked alphabet, that is, 
every constructor has a specific arity. We will denote constructors by upper case 
letters A, B,C,..., and implicitly specify their arity when creating constructor 
terms. 

Syntax Syntactically, the language Ac (Fig. I) consists of values and expressions. 
A value v is either an integer literal n, a constructor term C{vi, ..., v„) where 
C has arity n and Vi are values, a recursive unary^ function rec f x = e, 
or an explicit error err. An expression e is either a value v, an identifier x, a 
constructor term C{ei,... ,e„) where C has arity n and are expressions, a 
function application (e e), or a pattern-matching expression match e with P. 
Within the possibly empty list of patterns P, a pattern C{xi,... ,Xn) e 
consists of a constructor C with arity n, a list of variables a;i,... ,a;„, and a 
body expression e. For the list of empty patterns we write [ ] and to append 
lists we write [C{x-i,... ,Xn) —> e] -H- P. We assume that the constructors in a 
list of patterns occur at most once. We introduce an auxiliary definition v that 
represents values not containing functions. For constructor expressions with arity 
zero, we omit parentheses. 

Semantics In Fig. 2 we define the semantics of Ac as a small-step operational 
semantics. We use S to describe expressions with holes □ and Eval-Final to 
evaluate expressions containing only values as subexpressions. Eval-Hole eval¬ 
uates expressions by choosing holes. SApp defines recursive function application 
by capture-avoiding substitution of the argument and function symbol. The rule 
SMatch evaluates a constructor value and a list of patterns if the the construc¬ 
tor value matches the first pattern. If so, it extracts the values of the argument 
and substitutes the variables for the corresponding values in the pattern’s body 
expression. If the first pattern in the list of patterns does not match the construc¬ 
tor value, the rule SMatchNext applies and discards the first non-matching 
pattern. 

® Multiple arguments can be passed by wrapping them in a constructor. 



We explicitly define error creation and propagation as we want to detect def¬ 
inite errors in our programs. Errors occur, if the expression at the first argument 
of a function application is reduced to a non-function value or if a pattern match¬ 
ing expression occurs with an empty list either because no pattern matched or 
the list of patterns was initially empty. The former case, non-function values in 
applications, is handled by the rule SAppErrI and the latter case by the rule 
SMatchErr both reducing to the error value err. Error propagation is handled 
by the rules SMatchErr, if the argument to a pattern matching is an error, the 
rule SAppErr2 if the argument to a function application is an error, and the 
rule SMatchNextErr, if a constructor contains an error as a subexpression. 


V ::= n | rec f x = e \ C(vi ,..., v„) | err 

e ::= V \ X \ C(ei,..., e„) | (e e) | match e with [Ci{x) —>■ d] 

V ::=n j C(vi ,... ,a„) 


Fig. 1. Syntax of Ac with values v, expressions e and non-function values v. 


£ ::= C(ui,..., Vn, Cm) | □ 6 | u □ | match □ with [Ci{x) —>■ d] 


Eval-Final Eval-Hole 
/ / 
e —> e e ^ e 


e ^ e 


£[e] ^ £[e'] 


SApp ((rec f x = e) v) 

SAppErrI (D v) 

SAppErr 2 ((rec f x = e) err) 

SMatch match C{v) with [C{x) —>■ e,... ] 

SMatchErr match err with [... ] 

SMatchNext match C{v) with [D{x) —>■ e] -H- F 
SMatchNextErr match C{v) with [ ] 

SCtorErr C(ui, ..., Un, err, ei,..., Cm) 


■ e[x !->• u, / i-A- rec f x = e] 
err 

err 

■ e[xi i-s- Vi] 
err 

match C{v) with P 

err 

err 


Fig. 2. Small-step operational semantics for Ac- 



3 Type and Crash Condition 


The basic notion of our formalization is a type r that represents trees created 
from constructors C on a type level. Furthermore, we represent function values 
using recursive types. To formalize success types, we represent the possible out¬ 
puts of a function and the valid inputs of a function differently, thus resulting 
in a non-standard function type definition where the possible outputs are rep¬ 
resented using a type r and the possible inputs are represented using a crash 
condition <j). Types and crash conditions are defined mutually in Fig. 5. Intu¬ 
itively, a crash condition for a function is a logical formula whose models are 
types. These types describe inputs that definitely crash the function. 

Types r comprise of type variables a, an equi-recursive function type written 
^X.\/a [(/)] .T that includes a type variable a representing the function’s argument, 
a return type r, and a crash condition (j) indicating when the function definitely 
crashes. Furthermore, we define a constructor type r that captures the types of 
a constructor expression, a union type r U r, an integer type int, and the empty 
type T that has no values. We define two operators that work on types: a type- 
level function application (r @r t), and a projection function for constructor 
types r that projects the fth component of a type r if it is a constructor type 
C. The semantics of these operators is defined in Fig. 6 . In our definition, the 
fix-point formulation fxX only occurs together with a function type definition. 
The type operators are always implicitly applied. 

Crash conditions <j) are dehned as atoms true tt and false ff, intersection 
(j)\/ (j) and conjunction predicates over types C € t symbolizing that a type 

T can be a constructor C, C ^ t symbolizing that a type r is not a constructor 
type C, and W ^ t symbolizing that r is not a function. Furthermore, in Fig. 6 
we dehne an operator (r @0 r) that describes a crash-condition-level function 
application. Again, the crash condition operator is implicitly applied. 

An interpretation JA is a mapping of type variables to types. An interpretation 
of a type \t\j is a set of types as specihed in Fig. 3. 


I/iA.Va [0] .t\j 
IC'(ri,...,r„)|j 
In U T2\j 

I-LIj 


U(«)} 

{/iX.Va [<!>] .T I r' € \t\j',J' = J\ {a}} 
{C(n,• • • ,n) I n e {nlj) 

Inlj- u Ir2l|j- 
{int} 

{} 


Fig. 3. Definition of an interpretation ,7 on a type r. 



In Fig. 4 we recursively define an entailment relation \= (j) for an interpre¬ 
tation J and a crash condition (/). 




tt 


ff 


4>i \/ 4>2 <= 


4>i a4>2 ^ 

=4> J \= 4>1 A J <1)2 

C G T 

=4> 3C{t) G {tIj 

C ir <= 

=4> ^(C'(r)) G It\j 

V ^ r ^ 

=4> ${pXAIa[<j)\ .t) G H 


Fig. 4. Definition of the entailment relation J (j>. 


Example 1. We take the length function of lists as an example using constructors 
Cnii,Czero,Csucc, and Ccons with arities zero, zero, one, and two, respectively. 

reC leTl X — match X with \Cnil f ^ 2 ) f Csucc(^(J‘^^ ^ 2 ))] 

A possible function type for the length function is 


f/en — fxX ex 


Cnil ^ 01 l\ ^ (^Ccons G a A (X @0 V Ccons ^ 


Czero U CsucciiX @r 


whose type is recursively entwined with its crash condition. The derivation of 
this type is described in Section 3.1. We extract the crash condition that still 
makes use of Tien via X and get a logical formula with free variable a 

4*len — Cnil ^ CX A {^(^^cons G Cl A (tj Cl 4^2 ^ Ccons ^ 0^ 

that symbolizes when the function crashes. For example the following interpre¬ 
tation (amongst many others) 

J = {a l-> (J{((y^X.Va [ff] .Czero U Ccons (t, {X @r «))) @0 Cunused) I T G T} 

entails the crash condition: J \= (pien- Here, Cunused is only needed as a dummy 
argument to the type-level function. When implicitly applying the type opera¬ 
tors, we end up with the infinite type^ 

{^iX •Czero U Ccons (r,X) ItGT} 


This type represents all lists not ending with a nil but with a zero. 



r :;= a I pX.Va [(j)] .r | , r„) | r U r | int | ± | (t @t t) | 

<j> ff|tt|(^V 0 |(?!>A(?l)|CGr|C^r|V^r|(T t) 

Fig. 5 . Definition of types r and crash conditions 4>- 


Th[a T2, X ri] if ri = /rX.Va [ 0 ] .rt 

(ri @T r2) if ri = a 

(ri 7-2) = < (m @r r2) U (ri2 @t T2) if ri = m U ri2 
(ri r2i) U (n @T 7-22) if T2 = T21 U T22 
± otherwise 

{ Ti if T = C(ti, T„), 1 < i <n 
rXi if To = a 
± otherwise 


(?!>[a i-A r2, X H->■ ri] 

(n ®4, T2) 

(n T2) = < (rii T2) U (ri2 T2) 

(n r2i) U (ri ©.^ r22) 

tt 


if n = fiX.\/a [ 0 ] .Tb 
if n = a 
if n = Til U T 12 
if T2 = T21 U T22 
otherwise 


Fig. 6. Type and crash condition operators. 



Before introducing the analysis that assigns types and crash conditions to 
expressions, please note that the question of entailment is not decidable in gen¬ 
eral. 

Lemma 1. It is undecidable whether for an arbitrary crash condition 4> there 
exists an interpretation J such that J \= (f). 

We discuss possible solutions to this problem in Section 4. 


3.1 Analysis 

We present our analysis as a type system using a judgment F \- e : t Sz f that 
relates a type variable environment F, an expression e, a type t of the expression, 
and a crash condition f characterizing when the expression crashes. We define 
the derivation rules in Fig. 7. 

The rule T-Rec derives a recursive function type for a recursive function 
expression by inferring the body’s type and crash condition using type variables 
for the argument and a recursive type formulation for recursive calls. For a 
function application (T-FunApp) we infer types and crash conditions for both 
the callee ei and the argument 62 . The result type of the function application 
is the type-level application of the types of the callee and the argument. The 
function application can crash if either ei or 62 crashes, ei is not a function, 
or the application itself crashes. The latter is symbolized by a crash condition- 
level function application. The rule T-Identifier derives the type of a variable 
from the environment and never crashes. An error value err has type T and 
always crashes (T-Error). In rule T-Constructor, a constructor expression 
has a constructor type with the types of its arguments inferred recursively. A 
constructor crashes if one of its arguments crashes. Integer literals are handled 
by T-Integer and always have type int and never crash. 

For the pattern matching expression, the type is described by the union of 
the types of the expression in the patterns. The crash condition is described by 
the crash condition of the expression to match and the crash conditions of the 
cases. The crash conditions of the cases are built using an auxiliary judgment: 
(j)rn]T[)]F \-p P •. Tp k, 4>p where (pm describes the crash conditions accumulated 
so far, To describes the type of the expression to match, P the list of patterns 
which are traversed and Tp the union of the types of the pattern case’s body 
expression. The type and crash condition of a pattern list is created by two 
rules: if the pattern list is empty, we return the bottom type and the crash 
condition accumulated to far. If the pattern list is non-empty, we create the type 
of the current body expression by binding the variables defined in the pattern 
and inductively applying the derivation. The current expression can crash, if 
either the pattern matches (C G tq) and the body expression crashes, or if the 
pattern does not match at all. 

^ For the sake of a simpler type syntax, this type cannot be represented using our type 
syntax directly. We always have to use type-level applications. 



Additionally, we define a subtyping relation <: r x r in Fig. 8 The relation is 
standard, except for the rule S-Fun, which requires a logical implication of the 
crash conditions. 

The (output) types derived for an expression are over-approximations whereas 
the crash conditions describe the possible crashes exactly. The interplay of types 
and crash conditions ends up with definite errors, because the predicate C ^ r 
describes the question whether it is not possible that the type r is a constructor 
C, and similarly for the predicate V ^ t. 


T-Rec 

r, Xr : Or, /r : A h e : Te & (?!>e Q-r fresh Xr, fr ^ dom(F) 
r \- rec fr Xr = e : flX.^Or {4>e\ -Te & ff 


T-FunApp 

r I- ei : Ti & </)i T-Identifier 

r \- 62 '■ T 2 &L 4>2 r{x) = T 

r h (ei 62 ) ■ (ti @t T 2 ) & (ti r 2 ) V (?ii V 02 VV ^ Ti F h a; : r & ff 

T-Error T-Constructor 

Vi e {1,..., n} : r h Ci : Ti & 0i 

rherr:_L&tt F h ^(ei,... , e„) : C(ri,..., r„) & \/^ 

T-Pattern-Matching 

tt; To; r \-p P : Tp (fp 

F h eo : TO & 00 

F h match eo with F : Tp & 0o V 0p 
T-Pattern-Next 

00 A ((<7 £ To A 0e) V C ^ To); tq- r \-p P : T & 0 T-Pattern-Empty 

F, Xi : To if b e ; Te & 0e i = 1,..., n 

0o; To; F \-p [C{xi,.. . ,x„) ^ e] -b F : t' U Te & 0' 0o; to; F hp [ ] : T & 0o 

Fig. 7. Derivation rules for the types and crash conditions. 


T-Integer 


F h n : int & ff 


3.2 Properties 

To justify our analysis, we prove the preservation of types and crash conditions 
and the correctness. To do so, we need several auxiliary lemma. 

Weakening allows the introduction of a fresh type variable into the type 
environment without changing anything. 

Lemma 2 (Weakening). For expressions e, types t, Ty, and tq, an identifier 
y, conditions 0 and 0o, and an environment F, the following holds: 

1. If F \- e : T and y fz. dom(F) then F,y : Ty \- e : t Sz 



S-Bot 


S-Union 


_L<r T < T VJ t' 

S-Fun 

T <t' (f)' ^ <j> 

/iX.Va [0] .r < pX.Va [cf)'] .t 


S-Refl S-Ctor 

f < t' 

T < r C{f) < C{t') 

T-Sub 

r \- e ■. T &L (j) T < t' (j) ^ (j> 
r \- e ■. t' (f> 


Fig. 8. Subtyping rules. 


2. If 4>o; tq; r \-p P : T Sz (j) and y ^ dom(/^) then (fo; tq; r,y : Ty \-p P : t Sz (p. 

The next lemma shows that we can replace a type variable a within an 
environment by a concrete type a if we replace all occurrences of the type variable 
in the resulting type and crash condition. We need this lemma when working 
with the type-level function application. 

Lemma 3 (Consistency of type substitution). For a well-formed environ¬ 
ment P, an identifier y, a type variable a, an arbitrary expression e, types r and 
Ta, conditions (p and (po the following holds: 

1. If P, y : a \- e : T Sz (p then {P, y : a)[a Tq,] h e : T[a i—>■ Ta] Sz <p[a i—>■ Ta] 

2. If (po;To;P,y : a \-p P : t k (p then (po[a Ta];ro[a i-)- Ta];iP,y : a)[a 

Ta] bp P : T[a I—>■ Ta] k <p[a I—>■ Ta]- 

Item 2 shows that we can substitute a variable y in an expression e with a 
value of the same type without changing the type and crash condition of the 
whole expression. This lemma is needed for the type-level function applications 
later. 

Lemma 4 (Consistency of value substitution). For an environment P, an 
identifier y, types r and Ty, an expression e, conditions (p and (po, and a value 
V, the following holds 

1. If P, y : Ty \- e : T k (p and P \- v : Ty k ff then P b e[y v] : t k (p. 

2. If (Po;tq; P,y : Ty bp P : r k (p and P \- v : Ty k ff then (po;To;P bp 
P[y v] : T k (p. 

The next lemma shows that the analysis is designed such that after a suc¬ 
cessful pattern matching, the crash conditions of the remaining pattern’s body 
expressions cannot be satisfied anymore. The reason is that (po in the rules T- 
Pattern-Next and T-Pattern-Empty influences the resulting crash condi¬ 
tion of the whole expression. 

Lemma 5 (Unsatisfiability after matching patterns). For an environment 
P, types T and t', and conditions cp' it holds that ifff,To;P \-p P : t' k (p' then 
t^(P'. 



Finally, we can establish the preservation theorem for our type system. 

Theorem 1 (Preservation of types and crash conditions). //The: 
T Sz (j), e ^ e' and F h e' : r' & 0' then t <t' and 0 -O- 0'. 

Furthermore, we show that our analysis is sound: if the crash conditions 
report an error, then there is either an error or the evaluation does not terminate. 

Theorem 2 (Failure). //VT, V,F and \/x € dom(F); F V(x) : T{r{x)) N 
T(0), and 

1. r \- e : T (j), then V(e) err or V(e)t|'. 

2. 0o; To; F Fp {Ci{x —>■ ei),..., Cn{x —>■ e„)] : t h (j) and a value C{vi ,..., v„) 
with r' F C{vi, ..., Vn) '■ Clji, ..., r„) & ff , then either 

- yi: a 

— or 3i : Ci = C and (V'{ei) •^* err or V(ei)fi). 


4 Practical Considerations 

We have shown that success typing is an instance of falsihcation and thus allows 
the detection of dehnite errors. However, as shown by Lemma 1, the satishability 
of 0 is undecidable in general. Thus a direct algorithmic solution cannot exist. 
We implemented^ a version of the analysis that imposes a user-dehnable limit 
of k iterations on the unfolding operations described in the operators in Fig. 6 
and can thus check for errors up to depth k. 

Example 2. An example for a yet problematic combination of type and crash 
condition we cannot solve at the moment is the following: We create a function 
that generates an inhnite list and apply the resulting stream on the list length 
function. 

With the list generator’s type 
^gen — ((^A.Va [ff] 

■Ccons {C,ero, (X @r a))) @r Cunused) 

— CconsiCzero^ iTgen Cunused)) 

and the list’s type from Example 1 the application of the stream to the length 
function has the following crash condition after type and crash condition oper¬ 
ators are applied once (before substitution): 

(Cmi iah [(Ccons & a a 4 .^“"'’)) V C^ons ^ a)) 

^ CconsiCzero-} iEgen Cunused))) 

After performing the substitution, we can evaluate the predicates that only look 
finitely deep into their argument. When we apply type and crash condition 
operators again, we end up on the same crash condition. Although we reach 
a fix point in this case, this is of course not the case in general. 

® http://www.informatik.uni-freiburg.de/~jakobro/stpa/ 



To solve this problem in general, we need to find an approximation for the 
crash condition formula. As we only want to find definite errors, our approx¬ 
imation has to be an under-approximation. However, finding a good under¬ 
approximation, is yet an open problem. 

When we view the output type of a functions as a constructor tree, we can 
represent it as a higher-order tree grammar, as is proposed by Ong and Ram¬ 
sey [12]. The (approximated) crash condition of a function can be represented 
as a tree automaton. As the model checking of tree automata and higher-order 
tree grammars is decidable [11] we have some means of finding definite errors. 


5 Related Work 


The idea of finding definite errors in programs is quite old and several approaches 
exist. 

Constraint-based analyses to detect must-information can be found in Reynolds 
[13] where he describes a construction of recursive set definitions for LISP pro¬ 
grams that are “a good fit to the results of a function”. However, the goal of 
the paper was to infer data structure declarations and not to find errors. The 
constraint-based analysis of Lindahl and Sagonas’ [10] is a modular approach 
similar to ours, but does not account for data structures of arbitrary depth 
but instead uses k-depth abstraction as we do in our current implementation. 
Furthermore, the approach of Lindahl and Sagonas uses union types that are 
widened after a fixed size limit. These limits are to establish small and readable 
types whereas we focus on exact tracking of values. 

Soft typing, presented by Cartwright and Fagan [4] detects suspicious ex¬ 
pressions in a program, i.e., expressions that cannot be verified to be error-free, 
and adds run-time checks. Although the idea of not rejecting working programs 
is the same, our approach requires no changes in existing programs as we only 
assume programs to contain errors if we can proof it. 

The line of work of Vaziri et al. [5, 7] focuses on imperative first-order lan¬ 
guages and uses user-defined specifications given in the Alloy language to state 
the intention of a function and then checks the implementation against its spec¬ 
ification. Although they explicitly mention unbounded data structures in their 
approach, only instances up to a number of heap cells and loop iterations are 
considered. In contrast to our approach, they require user-defined annotations. A 
similar framework [15] removes the chore to define annotations and only requires 
the user to provide a property to be checked. Their abstraction refines specifi¬ 
cations that describe the behavior of procedures and thus creates a refinement- 
based approach that ensures that no spurious errors appear if the analysis halts. 

Different approaches for definite error detections are presented by Ball et 
al. [1] and Kroening and Weissenbacher [9] for imperative first-order languages 
in a Hoare-style way. However, a comparison to our approach is difficult because 
they rely on a transition system to model the behavior of programs whereas we 
use a type system. 



6 Conclusion 


We presented a new formal approach to success typings for a constructor-based 
higher-order language using different representations for the input and output 
type of a function. We proved that our formulation of success typings is a falsifi¬ 
cation in the sense that it only reports definite errors. We presented a prototype 
implementation that checks for errors up to a user-defined bound. 

In future we want to look at means to model check (type) trees [11,12] with 
logical formula represented as higher-order tree grammars and tree automata, re¬ 
spectively. Thus, we hope to (partly) remove the n-bound of current approaches. 
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A Proofs 


For the sake of completeness we enlist the substitution of variables and of type 
variables in Figs. 9 and 10, respectively. 


xlx !->■ u] 
y[x !->■ ii] 
n[x !->■ u] 
C(e)[x !->■ ii] 
((e e))[x !->■ w] 
{[Ciiy) -s- e])[x ^ w] 
rec f y = e{x i->- w] 
rec f y = e[x i->- w] 


V 

y 


n 


C{e[x !->•«]) 


{e[x u] e{x !->■ u]) 


[Ci{y) e[x ^ w]] 

x ^ {y} 

rec f y = e[x w] 

X i {/, y} 

rec f y = e 

X e {/, y} 


Fig. 9. Substitution of variables. 


Proof (Lemma 1). As types and crash conditions contain type-level functions, 
applications, and constructors, the crash conditions are Turing-complete and 
thus satisfiability is not decidable. 

Proof (Item 2). Proof by induction on the derivation of the analysis. 

Case T-Integer: Let P' = r,y : Ty. Then, T' h n : int & f f trivially holds by 
T-Integer. 

Case T-Identifier: We assume T h a; : t & ff and y ^ dom(T). Then, we 
have two subcases: 

Subcase x = y: By inversion, we get r{x) = r{y) = r. Thus, y € dom(T) 
which contradicts our assumption. 

Subcase x ^ y. By inversion, we get r{x) = t. Let P' = r,y : Ty. Then, 
r'{x) = T still holds and we apply T-Identifier and conclude P' \- x : 

T & ff. 

Case T-Constructor: By assumption we have both 

P \- C(e) : C (t) Sz V (p 
y ^ dom(T) 


Using inversion we get 

P h a : Ti k (pi 

for i = 1,... ,n. On each of these judgements, we can apply the induction 
hypothesis, and deduce 


r,y : Ty \- d : Ti k (pi 



q;[q; I—>■ r] = r 

/3[a t\= fi 

_L[q; I—>■ t] = X 
C{f)[a !->■ r] = C(T[a !->■ r]) 

(ri U r 2 )[a !->■ t] = ri [a t] U T 2 [a i—>■ r] 

fiX.\/a [cj)] .T[a H->■ r] = fiX.\/a [0] .r 

jj,XXp [4>\ .r[a !->■ r] = /iX.V/3 [(?!>[a r]] .r[a i->- r 

intfo; I— >■ r] = int 

(ti T2)[a I—>■ r] = (ri[a i—>■ r] T2[a i—>■ r]) 
ri? [a !-)■ t] = (T[a T])i? 

ff [a 1-^ r] = ff 
tt[a 1-^ t] = tt 

00 A 01 [a 1-^ t] = 00 [a I—>■ r] A 0i [a r] 

00 V 01 [a 1-^ t] = 00 [q; h->■ r] V 0 i[a i—>■ r] 

C € r[a 1-^ t] = C G (rfa i—>■ r]) 

C ^ r[Q; I—>■ r] = C ^ (rfa i—>■ r]) 

V ^ r[Q; 1-^ r] = V ^ (r[a i->- r]) 

(ri T2)[a 1-^ r] = (ti[q; t] r2[a r]) 


Fig. 10. Substitution of type variables. 



Finally, we apply T-Constructor and conclude that 
r,y:Ty\- C(e) : C{t) k \J ^ 

holds. 

Case T-FunApp: We assume 

r h (d 62 ) : (ti @r T 2 ) & (ti @0 T 2 ) V (/)i V 02 V V ^ Ti 
y ^ dom(A) 

By inversion we get 

F F Ci : Tj & 

for i = 1, 2 and apply the induction hypothesis on both of them. With 

r,y : Ty \- Ci : n k 4>i 

we can apply T-FunApp and conclude 

r,y :Ty\- (ei 62 ) : (n T 2 ) k (n @ 4 . T 2 ) V 0i V 02 V V ^ ri 

Case T-Rec: We assume 

r h rec fr Xr = e : rec = ipe k ff 

y ^ dom(F) 

By inversion we get 

F, Xr : ar, fr '■ TGC A = 0e 6 : Tg & 0e 

By alpha-conversion we can assume that Xr ^ y and fr yf y. Thus, with 

y ^ dom(F, Xr : fr ■ rec ar Tg = 0g) 

we apply the induction hypothesis and get 

F, y . Ty , X 7 . . ■ rec Tg — 0g F e . Tg & 0g 

As all preconditions still hold, we can apply T-Rec and finally conclude 

F, y : Ty F rec fr Xr = e : rec ar Te = 4>e k ff 

Case T-Pattern-Matching: By assumption we have 

F F match eg with [Ci{x) d Cj] : r & 0o V 0' 
y ^ dom(F) 

We use inversion to deduce both 


tt;To;F Fp [Ci{x) e,] : r & 0' 



and 


rh eo : To & 00 

We can directly apply the induction hypothesis on both judgements and 
obtain 

tt;To;r,y : Ty \-p [Ci{x) e^] : r & 0' 

and 

r, y : Ty h Co : To & 00 

respectively. Applying T-Pattern-Matching concludes 

r,y : TyV- match Co with [Ci{x) —>■ e^] : r & 0o V 0' 

Case T-Pattern-Empty: Let F' = r,y : Ty and 

0o;To;r' hp [ ] : _L & 00 

trivially holds by T-Pattern-Empty. 

Case T- Pattern-Next: Assume 


0o; To; F \-p [C{xi ,..., a;„) e] -H- A : r' U Tg & (0o A C e ro A 0e) V 0' 
y ^ dom(E) 

By inversion we get 

{4>0 /\C ^ To); To; E hp i? : r' & 0' 

and 

F,Xi : Toj-fb e : Te & 0e 

for i = 1,... ,n. By alpha-conversion we know, that Vi = 1,... ,n. Xi y. 
Thus, we can apply the induction hypothesis on both judgements and get 

(00 A C ^ To; To; E, y : Ty hp i? : t' & 0' 

and 

E, y : Ty, Xi : To^fh e : Tg & 0e 

respectively. Now we apply T-Pattern-Next and conclude 

0o;To;E,y : Ty hp [C{xi ,..., x„) -)• e] -ff E : t' U Tg & (0o A C € To A 0g) V 0' 

Proof (Item 2). Proof by induction on the derivation of the analysis. 

Case T-Integer: Let F' = {F,y : a)[a ^ Tq]. By substitution and T-Integer 
our consequence 

E' h n : n[a i-A Tq] & ff [o? i—>■ Tq] 

immediately holds. 

Case T-Identifier: We have two subcases. 



Subcase y = x: We have to show that 

(r, y : a)[a ^ Ta] y: Ta Sz ff 
holds. We apply inversion and get 

{{r,y : a)[a Ta]){y) = 

By definition of substitution this is equivalent to 

{r[a i-^Ta],y : Ta){y) = Ta 

As we require F to be well-formed this holds trivially. 

Subcase y ^ x: As assumption we have 

{r, y : a)[a Ta] \- x : a' h ff 

By inversion we get {r,y : a)(x) = a' . Thus, we know that F = Fi,x : 
a', F2. As F is well-formed, we can insert a substitution without changing 
the equality 

{{Fi,x : a',F2,y : a)[a >-)• Tq,])(x) = a' 

Now, we can apply T-Identifier and finally get 

{Fi,x : a', F2,y •. a)[a ^ Ta] x •. a' k, ff 

which is equivalent to our goal 

(T, y : a)[a Ta] \- x •. a [a ^ Ta] & ff [a 1-^ Ta] 

by the rules of substitution. 

Case T-Constructor: On the assumption 

F,y : a \- C{e) : Or) & V 0 

we apply inversion and get 

F,y ■. a\- Ci : Ti k (l)i 

With the induction hypothesis, we can deduce 

(T ,y : a)[a^ Ta] h e* : rja Ta] k (j)i[a ^ Ta] 

Applying T-Constructor yields 

{F,y : a)[a 1-^ Ta] b C{e) : C'(t[q; Ta]) k V { 4 )[a ^ Ta]) 
which is, by rules of substitution, equivalent to 

{F,y : a)[a >-)• Ta] b 0(0) : C(f)[a >-)■ Tq] k (V^)[q; i-^. Ta] 



Case T-FunApp: On the assumption 

r,y : a\- {ei € 2 ) : (n T2) & (n T 2 ) V 4>i V (j )2 ^ ^ n 

we apply inversion and get 

r,y ■. a\- Ci : Ti k (j)i 

With the induction hypothesis, we can deduce 

(F ,y : a)[a^ Ta] h e* : Ti[a Ta] k 4)i[a i-)- Ta] 

Applying T-FunApp yields 

{r,y : a)[a Ta] F (ei 62 ) : {Ti[a Ta] @t T 2 [a Ta]) 

k ( ti [ q ; !-)■ Ta] @0 T2[a !-)• Ta]) V </>! [« Ta] 

V 02[Q; !-)■ Ta] VV ^ Ti[a !-)■ Ta] 
which is, by rules of substitution, equivalent to 

(r ,y : a)[a Ta] F (ei 62) : (n @r T2)[a >-)■ t^] 

& ((ri @0 T 2 ) V </>! V 02 V V ^ Ti)[a >-)■ r^] 

Case T-Rec: We assume 

F, j/ : a F rec fr Xr = e : fiXkar [4>e] -Te k ff 
By inversion we can follow that y ^ fr, y Xr, and a ^ ar- Additionally, 
F, y . Cr, fr • kOir [0e] Xr • CTr F 6 . Tg & 0e 
With the induction hypothesis we get 

(F ,y : a,fr : yXXar [0e] •'Tg,: ar)[a Ta] F e : Tg[a i-> Tq] & 0g[r Tq,] 

When we apply T-Rec and exploit substitution we finally obtain 

(F, y : a)[a I—>■ Tq,] F rec fr Xr = e : (yXXar [0g] •Tg)[a i—>■ Ta] k ff 

Case T-Pattern-Matching: We have the assumption 

r,y : ah match eo with [Ci{x) —>• ei] : r & 0o V 0' 

By inversion we get two judgements. On the first, F, t/ : a F eo : tq & 0o, we 
apply the induction hypothesis and get 

(F ,y : a)[a^ Ta] F eo : To[a Ta] k 0o[q; Ta] 

On the second judgment 

tt; To; F, y : a Fp [Ci(x) -)■ ei] : r & 0' 



we apply the induction hypothesis, too and obtain 


tt[a Ta\-,To[a !-)• Ta]; {r,y :«)[«!-)• t^] \-p [Ci{x) e,] 

: T[a 1-^ Ta] & (j)'[a t^] 

Now we can apply T-Pattern-Matching and conclude 

{r,y : q;)[q; i-A Tq] h match eo with [Ci{x) — )• d] 

: T\a H- Ta\ & {4)0 V 4)')[a i-A r^] 


Case T-Pattern-Empty: The consequent 

4)o[a H- Ta];ro[Q; H> Tq,]; {r,x : a)[Q; Ta] bp [ ] 

: _L[a I— >■ Ta] & </<o[<a l-A Ta] 


holds by T-Pattern-Empty. 

Case T-Pattern-Next: As assumption we have 

4o;To;r,y : a hp [C{xi, ...,x„) ^] -H- P 

: t' U Te & (00 AC S To A 0e) V 0' 

By inversion we get two judgments. As first we get 

r,y : a,Xi : Tolf\- e : Te Sz 4>e 

for i = 1,..., n with : y ^ Xi hy alpha conversion. Now we can apply the 
induction hypothesis and obtain 

{r, y : a,Xi : Toif )[a Ta] b e : Te[a l-A Ta] & 0e[a Ta] 

for i = 1,..., n. On the second judgment 

(00 A C ^ To); To; r,y : a \-p P : t ' &z 4)' 
we apply the induction hypothesis and deduce 

(00 A C ^ To)[a i-A Ta];To[a Ta]; {r,y : a)[a Ta] bp P 

•. T [a ^ Ta] & 0 ^[q; I—>■ Ta] 

Finally, we apply T-Pattern-Next and conclude that 


0o[a i-A Ta];To[a Ta];P,y : a bp [C{xi,. .., a;„) -)• e] df P 

: (t' U Te)[a Ta] & ((00 A To G A0e) V 0')[a l-A Ta] 


holds. 


Proof (Item 2). Proof by induction on the derivation of the analysis. 



Case T-Integer: The consequent T h n[y i—>■ n] : n & ff trivially holds by 
T-Integer. 

Case T-Identifier: For this case we have two subcases. One with y = x and 
one with y ^ x. 

Subcase y = x: We have the assumptions 

r,y : Ty y : T k ff 
r \- V : Ty k ff 

By inversion we get (T,y : Ty){y) = r and thus, t = Ty and F \- v : 
T k ff. By applying substitution on our goal 

r F y[y v] : T k ff 

we get r \- V T k ff and are done. 

Subcase y ^ x: We have the assumptions 

r, y : Ty \- X : t k ff 
r \- V : Ty k ff 

By inversion we get {F, y : Ty){x) = t. Thus, F = Fi,x : t, F2 which leads 
to {Fi,x : t,F2){x) = t. This is a precondition for F,x : t \- x : t k ff 
which by rules of substitution is equivalent to F, x : t \- x[y v] : t k ff. 
Case T-Constructor: Assume 

F,y :Ty\- C{e) : C{t) & V ^ 


By inversion we get 

F,y : Ty \- Ci : n k cj)i 

for i = 1,..., n and apply the induction hypothesis. Thus, we obtain 


F h ei[y 1 -^ v] : Ti k 4>i 


and can apply T-Construgtor and conclude 

F \- C{e[y v]) : C (t) k V ^ 

which is by substitution equivalent to 

F \- C{e)[y 1 -^ v] : C (t) k V 4> 

Case T-FunApp: Assume 

F,y :Ty\- (ei 62 ) : (n T 2 ) k (n T2) V (jji V (j)2 V W ^ n 


By inversion we get 


F,y : Ty \- d : Ti k 4>i 



and apply the induction hypothesis. Thus, we obtain 


r h ei[y ^ v] ■. Ti k (j)i 


and can apply T-FunApp and conclude 

r h {ei[y v] e 2 [y u]) : (n @r T 2 ) & (n T 2 ) V </>! V (/)2 VV ^ n 
which is equivalent, by the rules of substitution, to 

r h ((ei 62 )) [y !-)■ v] : (n T 2 ) & (n @0 T 2 ) V (/)1 V (/)2 VV ^ Ti 

Case T-Rec: As part of the antecedent we have r,y : Ty \- rec fr Xr = 
e : rec ar Te = /pe k ff. By inversion we get r,y : Ty, fr : rec ar Te = 
4>e,Xr : CTr b e : Te k (j)e- Our induction hypothesis contains the antecedent 
r \- V •. Ty k ff but we need F, fr : rec ar Te = fie v : Ty k ff which we 
get using weakening (Item 2). Now we can apply the induction hypothesis 
and obtain F, fr : rec ar Te = fe, Xr ■ ar e[y 1 -^ v] : Te k fe- Applying T- 
Rec and the rules of substitution finally yields F h (rec fr Xr = e)[y ^ v\ : 
rec ar Te = <t>e k if. 

Case T-Pattern-Matching: We have F,y : Ty match eo with [C{x) —>■ 
Ci] : t k fo V f. By inversion we obtain tt-,T(f]F,y : Ty \-p [C{x) Ci] : 
t k f and C, y : Ty F eo : tq & ((>0 ■ We apply the induction hypothesis 
on both preconditions and get tt;To;C bp {CiX —> ei\[y ^ v] : t k f 
and F \- eo[y 1 -^ v] : tq k fo which are the preconditions for T-Pattern- 
Matching. We conclude by applying the rules of substitution and get F h 
(match Co with [C(t) ei])[y ^ v] : t k fo k f'. 

Case T-Pattern-Empty: Our goal, (j)Q;TQ;F hp {}[j/ i-A u] : _L & 0o, trivially 
holds by substitution and T-Pattern-Empty. 

Case T-Pattern-Next: We assume fo; tq; F, y : Ty hp {C{x) e};p : t' U 
Te & (00 A C € To A 4>e) V 0'. By inversion we get (1) (0o A C ^ To); To; F, y : 
Ty\-pp:t'k 0' and (2) F,y : Ty,Xi : tq 4-pb e : Te k fe with i = 1,... ,n. On 
(1) we can apply the induction hypothesis and get (0o A C.n ^ To); To; F hp 
p[y i-A u] : t' k 0'. On (2) the antecedent of the induction hypothesis does 
not fit C h u : Ty & ff. Thus we apply weakening (Item 2) and obtain 
F,Xi : To if V : Ty k ff with i = 1,... ,n. Now we can apply the induction 
hypothesis and get F,Xi : tq ifh e[y ^ v\ : Te k fe- Using the rule T- 
Pattern-Next and substitution, we conclude that 0 o;to;T hp ({C'(a;) —>■ 
^}\P)[y '->■ u] : f' U Te & (00 A C G To A 0e) V 0' holds. 

Proof (Lemma 5). Proof by induction on the derivation of hp. 

Case T-Pattern-Empty: For 

ff;To;F hp [ ] : T & ff 


we have h f f. 



Case T- Pattern-Next: We have 

(/)o; To; r hp [C{xi,... ,x„) -)• e] -ff P : r' U Te & ((/)o A C e tq A (/)e) V (/)' 

and know that (j)Q = ft. Thus, the crash condition simplifies to (ff A tq G 
/\4)e) y (j)' = (f)'. We have to show that (j)'. By inversion we get 

(00 A C ^ To); To; F \-p P : t' k (j)' 

and with 0 o = ff we get 

f f; To; r \-p P : t' k 4> 

Applying the induction hypothesis finally yields 0'. 

Proof (Theorem 1). We abbreviate £[e\ with e and £{F] with e', respectively. By 
induction on the derivation of e e'. In all the cases building on Eval-Hole, 
we have e e' by inversion on e e'. 

Case e = C{vi... ,Vn,e,ei,... ,em) ^ e' = (^(vi ..., v„, P, ei,..., e^): By 
assumption we have 

P b :C'(t„i „,f,Tei „,) k 0„, V 0 VV™ i0e, (1) 

PhC(ui,„„,e',ei...™) : C(t; „,f',T;_.) & V’Li 0 ^W 0 'V V™ ^ 0 '^ ( 2 ) 
Inversion on equation (1) yields 

P h Ui : Tuj k (fvi P \- Ci : Tei k 06^ P h e : f & 0 
and for inversion on equation ( 2 ) we get 

P \- Vi : k (f'y. P \- Ci : t(,. k P e' : t ' k (f' 

Thus, we can follow that t^^ = t(., Te^ = t(,., 4>v^ = 0(,^, and 0ej = 0e^. 
Additionally, we have (f = f'A0 -fA 0') ^ t = t'A0 = 0'. Now we can apply 
the induction hypothesis (PI-e:f&0Ae‘^e'API-e':f'&0'^f = 
f' A 0 -fA 0') and thus conclude that t = t' and (j) (j)'. 

Case e = (e 62 ) ^ e' = {e' 62 ): By assumption we have 

P h (e 62 ) :(f@,-T 2 ) & (f @0 T 2 ) V 0 V 02 VV ^ f (3) 

P b (e' 62 ) : (t' @ 1 - T 2 ) k (f' @0 T 2 ) V 0' V 02 VV ^ f' (4) 

When applying inversion on equation (3) we obtain 

Pbe:f&0 Pbe 2 :T 2&02 
and for inversion on equation (4) we get 

P b e' : f' & 0' P b 62 : T 2 & 02 

Thus, we have T 2 = T 2 and 02 = 02 and (f = f' A 0 fA 0') —>■ t = t' A 0 = 0'. 
We apply the induction hypothesis (Pbe:T&0Ae'^e'APbe' : 
t' & 0' —>• f = f' A 0 -(-A 0') and conclude that t = t' and 0 0 0'. 



Case e = {v e) ^ e' = (v e'): By assumption we have 

r \- (v e) : (ti @t t) & (ri f) V (/)i V ^ V V ^ ri (5) 

h (v e') : (ti @r t') & (ti f') V V V V ^ ti (6) 

Inversion on equation (5) yields 

r \- V ■. Ti k, (pi 

and inversion on equation (6) yields 

r \~ e' : t' k, p' r \" V ■. t'i k p'l 

Thus we conclude ti = pi = pi, and furthermore, {f = f' A p p') ^ 
t = t' Ap = p'. We apply the induction hypothesis (TI-e:f&0Ae‘^ 
e' AT \- C : t' k p' ^ f = t' Ap -vA p') and conclude that t = t' and p AA p'. 
Case e = match e with [C'(x) ^ e] e' = match e' with [C{x) e]: By 


assumption we have 

r h match e with [C(x) -A e] : Tp k pV pp (7) 

r h match e' with [C'(x) -A e] ■. r'p k p' W p'p (8) 

By inversion on equation (7) we get 

r \- e ■. T k p 

tt;f;T hp [C(x) -A e] : Tp k pp (9) 

and by inversion on equation (8) we obtain 

rhe' -.t' kp' 

tt;T;r \-p [C'(x) -A e] : Tp k Pp (10) 


Now by applying the induction hypothesis (TI-e:f&0Ae>^e'ATI-e': 
t' k p' ^ T = t' A p AA p') we can conclude that the equations (9) and (10) 
are equivalent and thus, t = t' and p = p'. 

Now to the interesting cases. 

Case e = ((rec f x = e) v) ^ e' = e[x t-A v, f i-A rec f x = e\: By assumption 
we have 

r h ((rec f X = e v)) : (n T 2 ) k (n T 2 ) V pi W p 2 V y ^ n (11) 
on which we apply inversion (T-FunApp) and get 
r \- V : Tv k ff 

r h rec f X = e : rec a Tg = pe k ff (12) 



Applying inversion (T-Rec) on the second judgement (12) yields 

r,x : a, f : rec a Tg = (j)e\- e ■. Te (pe ck fresh (13) 

Thus, for equation (11) we have (Ti@T-r 2 ) = ((rec a Te = (j)e)@rTy) = Te[a ^ 

Ty] and (ti @^T 2 ) V^i V (/)2 VV ^ Ti = ((rec a Te = (j)e) @,j>Ty) Vff Vff VV ^ 

(rec a Te = 4>e) = <('e[Q! >—t Ty]. Our assumption can thus be rewritten as 

r h ((rec f X = e v)) ■. Te[a^ Ty] & <pe[c( Ty\ 

We now claim that the following holds 

r h e\x I—>■ V, / I—5- rec / x = e] •. Te{a ^ Ty] & 4>e[oi >—t Ty] 

To show that, we apply Item 2 and get 

r,x : a,f : rec a Te = <()e b e : Te & <()e A T h rec f x = e : rec a Te = </>£& ff —> 
r,x:a\- e[f rec / x = e] : Te & </>£ 

On the consequent, we apply Item 2 and get 

r,x : a \- e[f rec / x = e] : Te & ^(>6 —t 

r[a I—>■ Tt,],X : Tt, h e[f rec / x = e] : Te[xa i—>■ Ty] & 4>e[oc^ Ty] 

From equation (13) we know that a was fresh, and thus a ^ ran{r) which 
implies r[a Ty] = F. Finally, we again apply Item 2 and get 

r[a 1 -^ Tu],X : Tj, h e[f i— rec / x = e] : Te[xa i—>■ Ty] & 4>e[a^ Ty] 

A OhuiT^&ff—s- 

r h (e[/ rec / x = e])[x i-A w] : Te[a i-A Ty] & (j)e[a i-A Tt,] 

As X ^ /ree(rec / x = e), we can reorder the substitution and 

r h e[x I—>■ V, / I—s- rec / x = e] : Te[Q; i—>■ Tu] & 4>e[oi >—t Ty] 
holds, as claimed. 

Case e = match C{v) with C'(x) ^ e|r ^ e' = e[xi i-A v^] (i = I..., n): By 
our assumptions we know that 

F h match C{v) with C'(x) —>■ ejr : Tp Sz (j)o V (jjp (14) 

F h e[xt i-A Vi] (15) 

Now we have to show that Tp = t' and (jjQ V <f)p (f)' holds. By inversion on 
equation (14) we get two judgements: At first, F h C{v) : C(Ty) & ff which 
by inversion yields 


T h Ui : Tj & ff 


I = I,..., n 


( 16 ) 



and second, we get 

tt; C(f^); r hp C{x) e|r : Te U f & ((/)o A C ^ C'(^)) /\4>e)V ^ (17) 

We again apply inversion and by T-Pattern-Next get 

(00 AC ^ C'( 7 y));C(Ty);ri-p r : f & ^ (18) 

r,Xi : C{Tv)lf\-e : Te k (j)e (19) 

As we know that 0o = tt, C G C(t^} ~ tt, and C ^ C(t^) = ff (the 
pattern matches), we can change equation (18) to 

ff; C( 7 y); C Pp r : f & 0 

and then apply Lemma 5 and conclude P 0. Thus, equation (17) simplifies 
to 

tt; C( 7 y); C Pp C(x) e\r : Te U f & 0e 

Now we have to derive the types of equation (15) and show that Te U f = t' 
and 0e GA 0'. In equation (19) we can simplify C(Ty)4,f to Tj and then apply 
Item 2 (value substitution) n times using equation (16) with the appropriate 
i. Thus, we obtain 

r P e[Xn . [xi ?;i] : Te & 0e 

The substitution is order-independent as V0j : Xi ^ Vi and thus we get 

r P e[xi !-)• Vi] : Te & 0e 

By subtyping (Te < Te U t) our claim holds. 

Case e = match C(U) with D{x) —>■ e|r ^ e! = match C{v) with r: By 
assumption we have 

r P match C{v) with D{x) e\r : Tp k (j)Q y (fip (20) 

r P match Civ) with r ■. k (21) 

Our claim is that Tp < Tp and 0o V 0p ga 0q V 0p. To prove this, we apply 
inversion on equation ( 20 ) and obtain 

r P C(U) : C(t) k ff (22) 

tt; C(t); r Pp D(x) e\r :TeUT&ttACGZlA0eV0 (23) 

where the crash condition ( 0 o = ff) of equation ( 22 ) can be deduced by 
another inversion. Equation (23) can be simplified as we know that C G 
C = ff. Thus, we get 0 = 0p and (without simplifications) t = Tp. Inversion 
on the other assumption ( 21 ) again yields equation ( 21 ) and additionally we 
have 

tt;C(T);C Pp r : Tp & 0p (24) 

With the same reason as above, we can follow that 0o = 0 q = ff and thus 
0' = 0p. Inversion on both equations (23) and (24) requires a case distinction 
over r as both the rules T-Pattern-Empty and T-Pattern-Next match. 



Subcase r = [ ]: Inversion on equation (23) yields 


tt A (D e C{v) VD^ C(r)); C'(r); T hp [ ] : f & ^ 

By T-Pattern-Empty we get f = _L and ^ = tt. Thus, t = Tg U f and 
(j) = (j) = tt. With r = [ ] and T-Pattern-Empty equation (24) gets 
more specific: tt;C(r);T hp [ ] : _L & tt. It follows that Tp = _L and 
(j)' = tt and thus, our claim holds. 

Subcase r ^ []: Inversion on equation (23) now gives 

tt A (£1 G C(v) MDi C'(t)); C'(t); £ hp r : f & ^ 

This can be simplified by D ^ C(r) = tt to 

tt; (^(r); £ hp r : f & ^ (25) 

As we have deterministic rules, we can follow from the equivalency of 
equation (24) and (25) that f = and (j) = </>),. Thus, </> = </>' and t = t'. 

And finally, the error cases. 

Case e = (v v) ^ e' = err: By assumption we have 

r \- (v v) : t Sz (j) (26) 

£ h err : T & tt 

By inversion on equation (26) we also get £ h h : r* & f f. As D G {n, C'(T)}, 
we know that V ^ ts holds and thus, ^ = tt. But then, <l> = 4’’ E^nd t' < t. 
Case e = ((rec f x = e) err) ^ e' = err: By assumption we have 

£ h ((rec f X = e) err) : t (j) (27) 

£ h err : T & tt 

By inversion on equation (27) we also get £ h err : T & tt. Thus, (j)2 = tt 
which implies ^ = tt. But then, (j) = (j)' and t' < (ri @i- 'r 2 )- 
Case e = match err with P ^ e' = err: by assumption we have 

£ h match err with P -.t k, (p (28) 

£ h err : T & tt 

by inversion on equation (28) we also get £ h err : T & tt. Thus, (p = tt. 
But then, p = p' and t' < Tp. 

Case e = match C (JJ) with [ ] ^ e' = err: by assumption we have 

£ h match C{v) with [] : t k p (29) 

£ h err : T & tt 

by inversion on equation (29) we also get tt; tq; £ Pp [ ] : Tp & pp. By 
T-Pattern-Empty we know that Tp = T and <j) = tt. Thus, t = P and 
^ = tt. But then, (p = (j)' and t' < t. 



Case e = C(vi ,..., v„, err, ei,..., Cm) ^ e' = err: Assumptions give us 

r h C{vi ,... ,u„,err, ei ,... ,em) ■ t k (j) (30) 

r h err : _L & tt 

By inversion on equation (30) we get, amongst others, F h err : _L & tt, and 
thus, we can follow by T-Constructor, that </> = tt. We can now conclude 
t' < t and (j) = 0'. 

Proof (Item 2). For the simple cases e = {n, rec / x = e,C{v),x} the assump¬ 
tion does not hold, a.s F \- e : t & ff. 

Case e = err: Trivially holds. 

Case e = C{e): Holds by inversion, application of the induction hypothesis and 
application of SCtorErr. 

Case e = (ei 62): 

— Wlog assume 1= T(0i): Holds by inversion, application of the induction 
hypothesis and application of SAppErrI 

— Wlog assume 1= T(02): Holds by inversion, application of the induction 
hypothesis and application of SAppErr2. 

— Wlog assume 1= T(V ^ ri): We can assume that either V(ei) t|- or 
V(ei) V. For the former, clearly V(e) fl". For the latter, we apply 
Theorem 1 and deduce that v cannot be a function. Thus our claim 
holds by SAppErrI. 

— Wlog assume 1= T((ti @t T 2 )), 1^ T(0i), and T(02): We know that 

S App 

V(e) “M-* ((rec f x = e') v) ^ e". By inversion and application of the 
induction hypothesis our claim holds. 

Case e = match eg with [C{x) —)■ e']: 

— Wlog assume 1= T(0o): By inversion, application of the induction hy¬ 
pothesis, and SMatchErr our claim holds. 

— Wlog assume 1= T(0p): By inversion we get 


A) 5 P -P ■ A ^ 

Again by inversion we know that V(eo) C(v) with F F C{v) : 
C{t) & ff. Thus we can apply the induction hypothesis and get 

• that there is no matching constructor. Thus 

SMatchErr 

V(e) V(match C{v) with [ ] 

and by SMatchNextErr our claim holds. 

• that there is a matching constructor. Thus 

SMatohNext 

V(e) V(e") -A V(e') err 

For the pattern-matching cases we have get the following: 



Case TPatternEmpty: Trivial follows that there is not matching constructor. 
Case TPatternNext: There are two cases: 

— If the first constructor matches the constructor value, then 1^ T{(j)o) 
because it is the first match and Lemma 5. Furthermore, we have N 
T{C € tq). By assumption we conclude that N T{4>e) and thus apply the 
induction hypothesis on 


r,Xi : ro4,fl- e :Te Sz 4>e 


and our claim holds. 

— If the first constructor does not match, we apply inversion and the in¬ 
duction hypothesis and on the remaining patterns and get: 

• if there is no matching constructor our claim immediately holds. 

• if there is a matching constructor Cj with body expression Cj and 
V(ej) err or V{ej)'{[, then our claim holds for i = j -|- I. 



